1. Background and Relevant Art
As computerized systems have increased in popularity, so have the needs to store and backup electronic files and other communications created by the users and applications associated therewith. In general, computer systems and related devices create files for a variety of reasons, such as in the general case of creating a word processing document in a work setting, as well as creating a file used for more sophisticated database purposes. In addition, many of these documents can include valuable work product, or sensitive information that should be protected. One will appreciate, therefore, that there are a variety of reasons why an organization will want to backup electronic files on a regular basis, and thereby create a reliable restoration of an originally created file when needed.
One of the challenges facing organizations implementing one or more backup solutions is that data created and accessed within an organization can vary greatly (e.g., from simple word processing to database or system data). The various types of data may also be associated with varying levels of importance, which can in turn be associated with different backup protection needs. For example, some types of system data, which may not change frequently, may only need to be backed up every couple of days. By contrast, other types of sensitive mail or database data may change much more frequently, and thus may need to be backed up every few minutes. In addition, the needs to backup data with a particular frequency may often need to be balanced against system resource availability.
Complicating these issues is the notion that an organization might also implement different file systems, and/or mail and database systems at one or more different production servers, which can even be commingled. For example, users within the organization might access word processing or spreadsheet documents at one or more production servers, but alternatively access mail or other database program data at one or more different production servers. In some cases, the same production server may even host different types of data that vary widely in terms of how the various data need to be backed up.
Unfortunately, backup schematics are generally applied on a per-production server, or potentially on a per-volume basis. For example, a backup administrator might designate one or more production servers (or production server volumes) for one backup schema, and then designate one or more different production servers (or volumes) for a different backup schema. In turn, production server administrators might then place data (and applications) on the production servers that have been associated with a particular backup schema of interest. As a result, if data are moved from one production server to another, the data are likely to be associated with a different backup schema. Such dissociation of data from a particular backup schema can result in a number of inefficiencies, particularly where data that do not need to be backed up frequently are placed on a production server volume that is scheduled for frequent backups. Similarly, there may be some danger that more sensitive data are not backed up as frequently as possible when moved to the wrong production server.
An organization may attempt to ameliorate such problems by changing protection intents for particular production servers when needed. For example, a production server administrator might send one or more instructions to a backup administrator to adjust the backup intent at a particular backup application. The backup application might then adjust its activities in accordance with the new production intent, and then change how it instructs backup activities at the given production server. Alternatively, the backup administrator may make such a determination about backup schemas at production servers based on any number of factors, and then adjust the corresponding backup application accordingly.
Unfortunately, it may be difficult even for production server administrators to monitor the specific backup needs of each individual application or corresponding data on a particular production server. This is likely also true for the backup administrator who may even be further removed from the production server data activities. As a result, even adjusting protection intents at an administrator level for certain production servers may be insufficient as a means of ensuring particular backup schemas are associated with particular data and data types. While data creators (e.g., application end-users) may have a better feel for how the data they create should be protected, there is generally no mechanism for the end-user to assign a protection intent to a particular file. Rather, the end-user may be relegated to simply placing the file on a particular production server that is associated with a particular backup scheme.
Accordingly, there are a number of difficulties in the infrastructure and methods used in conventional backup systems that can be addressed.